The general structure of a network element may be divided into three main parts. There is a control part which may be constituted by the different computer units interconnected by an internal message bus. There is also a network interface part which comprises the access and trunk network interfaces. The network interface part is intended to interface the network element to another network element and to the user or users. Further, there may be a switching part which implements the connections between the different lines and/or trunk circuits. This general structure is only one example of the network element and it is derived from the structure of the conventional telephone exchange.
In the above example, counters or so-called memory banks may be used for saving or recording data about various parts or functions of the telephone exchange or network element. Traditionally, counters have been used in the telephone exchange for billing purposes between the operators. Despite the fact that the subscriber billing at present is fully based on CDR's (Call Detailed Record, CDR), the need for counters has not decreased.
Typically a telephone exchange, for example, records different counters which are directed or allocated to the same unique address. Examples of the addresses are a subscriber, a bus, a connection, an IP-address, a pair of virtual paths/virtual channels etc.
One example of the present counter handling in the telephone exchange is described in FIG. 1. The charging program in different charging units (CHU, Charging Unit) sends a plurality of updating messages to updating block (AUPPRB) in a master charging unit (CHU-1). Data from the updating block is written out from the charging unit by using a logical file CHSAVE. The updating of the counters cannot be divided into different charging units, which means that traffic load between different charging units is heavy. To add new counters to this structure is almost impossible. Also the updating block and the logical file are quite fixed in the platform software in the network element making them difficult to change.
Operators or other users of network elements usually have different needs or uses for counters which are to be recorded. In some situations, there may be a need for summing up a set of counters or collect all of the counters separately and obtain the specific information of the counters afterwards. It is not reasonable to combine traditional counter information and call detailed records, and it is not always even possible. It is more preferable to preserve the counters for different kind of information from the call detailed records.
In the future there might even be some network elements which do not generate call detailed records at all. As an example of this kind of network element let it be mentioned the service routing register (SRR, Service Routing Register), which provides a mobile number portability (MNP, Mobile Number Portability), and the media gateway (MG, Media Gateway), which provides a gateway solution between different protocols or networks.
In these network elements, the counters may be used, e.g. for counting the number of IP packets or for the billing between the Internet service providers. However, the known methods do not provide any tools for the operators or users of the network elements or counters to modify the data recorded on the counters or the way of updating or retrieving the changed data from the counters. At present, the counter data is collected separately and output via a logical file. All the operations and functions relating to the counters have been hard coded in the network element, and changing the handling of counters or specifying a new counter by the operator has been difficult or even impossible. Usually a small change to the counter handling process has required a lot of changes in the whole platform software in the network element or the telephone exchange. Thus, the operators and other users of network elements have found it inefficient and useless to handle the counters.
Thus, there is an increasing need for a dynamic counter handling process so that the process may be specified on product line basis or even on operator basis. There is also a need for such a counter handling process that does not load the internal message bus too much.